PLATFORM
  • Tails

    Create websites with TailwindCSS

  • Blocks

    Design blocks for your website

  • Wave

    Start building the next great SAAS

  • Pines

    Alpine & Tailwind UI Library

  • Auth

    Plug'n Play Authentication for Laravel

  • Designer comingsoon

    Create website designs with AI

  • DevBlog comingsoon

    Blog platform for developers

  • Static

    Build a simple static website

  • SaaS Adventure

    21-day program to build a SAAS

I Wrote More than 90 Articles on 2021: Here is What I Learned

I Wrote More than 90 Articles on 2021: Here is What I Learned

This article summarizes my experience as a writer during the pandemic year 2021

Below you will find lots of resources and tools and my method and tips for heavy writing.

My Background

  • I have a degree in computer science. πŸ‘¨πŸ½β€πŸ”¬

  • I use the scientific method and Occam's razor.

  • I have researched for 30 years both in the academic and industrial fields.

  • I don't have the absolute truth.

  • I try to support my opinions with evidence. πŸ”

  • They are my opinions and are very subject to change.

My tools and secret sauces

Time management

  • I read a lot of articles early in the morning and bookmark them during the day. πŸŒ…

  • I use Trello, Inoreader, Pocket, and Obsidian.

  • I Use The Pomodoro technique to focus when writing. πŸ…

  • I avoid perfection. I publish them when they are ready.

  • Then I make corrections with other people's comments. Even after months.

  • I Garden my articles.

Dealing with Criticism

  • I have different opinions than many other developers.

  • Software Design is a creative activity.

  • My articles are suggestions and not rigid rules.

  • I try to have smart discussions.

  • I have zero tolerance for hate speech and unprofessional comments.

  • I never feed the troll.

Common Criticism

  • I get the same comments over and over again, so these are the common critics I get and my opinions.

Readability

I need to see the complete code in a sheet

  • If you need to see long methods/scripts to understand your solution, that's fine.

  • I prefer to have small/reusable/testable functions.

The code in your articles is not Compiling/Working/has errors

  • I try to add code samples for clarity.

  • Most of the code snippets work.

  • Some of them are pseudo-code for educational purposes. πŸ‘¨β€πŸ«

  • I have used 25+ different languages in my articles.

  • I am not an expert in ANY of these languages.

  • Languages are accidental, Software design is essential.

I Have a trick in INSERT LANGUAGE to improve the code.

  • Most of the articles are language independent.

  • The solutions try to avoid language perks and cleverness.

Your solution is not performant/optimal

  • I write about backend business software. πŸ–₯️

  • This is the domain I've been working on.

  • I am aware that some tasks require more performant solutions (for example DApps).

  • I will always choose long descriptive names over smart performance optimizations.

  • First, make the code right. βœ”οΈ

  • Then, optimize it only if you have strong evidence.

  • Complexity is not enough evidence.

  • You need a real benchmark in real use case scenarios. πŸ“ˆ

  • If I need to sort 20 elements in a collection, I will always choose bubble sort because it is easier to read.

Premature optimization is the root of all evil. 😈

Helpers, DTOs, Singletons, Nulls, Setters, Metaprogramming, Castings, Comments are standard. πŸ™ˆ

  • I write a lot on these anti-patterns with the reasons why I think we should avoid them.

  • You can keep thinking they are good and that's fine.

  • My arguments against them are in all articles.

-I reply polite comments about them.

A 15 lines long method is not 'long'

  • IMHO, a 6 lines method is too long

  • You can always break them using refactorings. πŸ› οΈ

  • You don't need to see the big picture and the details at the same time. 🌳

  • Trust your implementation and write good tests.

Your solutions have too many indirections

  • Coupling is our worst enemy. πŸ™…

  • We need to avoid direct relationships.

You have too many rules and constraints

  • There is just one rule.

  • Always follow the bijection πŸ”€

Comments (0)

loading comments